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© A peer to peer connection authorizer is dis- 
closed. The connection authorizer involves three dif- 
ferent entities: a system authorizer mechanism, a 
client connection manager, and a server connection 
manager. The system authorizer resides on the main 
or primary CPU while the client and server connec- 
tion managers reside on individual lOPs. To obtain 
information required by a user and/or an application 
program, the client connection manager issues a 
request to the system authorizer. When the system 
authorizer receives the request, it first verifies that 
the client device is who it claims to be. If the system 
authorizer determines that the client device should 
be allowed to access the requested information, it 
then sends a token to the server device and a copy 
of the same token to the client device. Upon receipt 
of the token copy from the system authorizer, the 
client connection manager packages the token copy 
into a message that it sends to the server device. 
When the server connection manager receives the 
message from the client device, it compares the 
token copy to the token it received from the system 
authorizer. If the tokens match, the server connection 
manager responds to the client device and the con- 
nection is established. 
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This invention relates to the data processing 
field. More specifically, this invention relates to the 
authorization of peer to peer connections. 

Since early computer systems performed only 
simple tasks, it was unnecessary for them to in- 
clude more than one input/output unit (I/O unit). For 
this reason, computer systems such as the EDVAC 
device of 1948 contained only a single I/O unit. The 
I/O unit was merely the mechanism used by the 
computer system to communicate with the outside 
world. Since these early computer systems re- 
quired a relatively small amount of information, the 
I/O unit could be controlled by the central process- 
ing unit (CPU) itself. As time passed, the complex 
tasks performed by computer systems required 
access to more and more information. Direct con- 
trol of the I/O unit by the CPU was no longer 
practical. 

In 1959, Univac Corporation introduced its 
LARC computer system. The LARC computer sys- 
tem included an input/output controller (IOC) which 
was itself a genuine computer. The IOC was used 
to handle the flow of information to and from the 
outside world, thereby reducing the work required 
of the CPU. While the IOC controlled up to eight 
I/O channels, modern day computer systems usu- 
ally include a single I/O controller for each I/O 
channel. These I/O controllers are called in- 
put/output processors (lOPs). Similar to the IOC of 
the LARC computer system, lOPs are computer 
systems unto themselves. Each IOP is responsible 
for handling the information flow between a particu- 
lar external device (i.e., "the outside world") and 
the computer system. 

The wide use of lOPs has greatly improved the 
overall performance of today's computer systems. 
Computer systems can now communicate with a 
variety of external devices without overly burdening 
the CPU. Examples of devices which can be con- 
nected via lOPs include: terminals, magnetic stor- 
age units, optical storage devices, programmable 
workstations, and other computer systems. To the 
computer system, each of these external devices 
represents a resource that can be used to perform 
a specified task. In many cases, the task to be 
performed can be accomplished by the external 
devices without extensive intervention on the part 
of the CPU. This, of course, greatly reduces the 
work required of the CPU. 

Since today's multimedia applications typically 
require extensive access to audio and video in- 
formation, they are illustrative of the potential per- 
formance advantage of lOPs. The amount of data 
necessary to present a user with audio and video 
information is enormous. Hence, tremendous per- 
formance savings are possible in theory by allow- 
ing a multimedia application associated with an IOP 
to bypass the main CPU and access information 



from another IOP directly. Inherent in this noninter- 
ventionist approach, however, is the problem of 
securing information and resources. Allowing exter- 
nal devices to connect at will makes unauthorized 

5 use of system resources a real problem. Without 
some type of security, the users associated with 
the various external devices may attempt to gain 
access to personal or otherwise sensitive informa- 
tion. This problem is magnified when one considers 

w that the computer system, the various lOPs, and 
the attached external devices may be owned or 
manufactured by different parties. In this later, 
worse case scenario, rogue lOPs may actually be 
introduced into the computer system to facilitate 

75 the unauthorized use of system resources (i.e., to 
steal information). 

Solutions to this problem invariably involve 
some CPU intervention. Thus a balance is struck 
between efficiency and security. A computer sys- 

20 tern which is more secure tends to be less efficient 
while a computer system which is very efficient 
tends to be less secure. This tradeoff stems from 
the fact that highly secure computer systems must 
include a means (i.e., authorization means) to allow 

25 or disallow access to system resources. While au- 
thorization means do provide for increased secu- 
rity, they also create expensive performance over- 
head which reduces overall system efficiency. 
Hence, computer system designers are always at- 

30 tempting to design systems that are efficient yet 
secure (i.e., "to have their cake and eat it too"). 

A solution to a related security problem is an 
authorization model called Kerberos. Kerberos was 
jointly developed by Digital Equipment Corporation, 

35 International Business Machines Corporation (IBM), 
and the Massachusetts Institute of Technology 
(MIT) for use on an MIT campus-wide computer 
network. 

Kerberos uses a system of messages and keys 

40 to deal with the security problem. To obtain in- 
formation from a server device, a client device 
must first request authorization from a Kerberos 
server. This action triggers a series of encrypted 
messages which are sent by the Kerberos server to 

45 the client and server devices and from the client 
device to the server device. Eventually, the client 
device is able to connect to the server device. 

Although Kerberos is an illustrative solution to a 
related security problem, Kerberos was not de- 

50 signed to solve the problem of rogue lOPs. Further, 
the Kerberos authentication model is itself flawed in 
many respects. One problem with the Kerberos 
model is its inherent complexity. Each device that 
wishes to participate in the authentication scheme 

55 must first register itself with the appropriate Ker- 
beros server. To accomplish this, the subject de- 
vice must first have knowledge about the resources 
controlled by particular Kerberos servers and then 
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register with the appropriate Kerberos server or 
servers. The registration process is itself complex 
in that each Kerberos server must allocate a unique 
encryption key to each device. If multiple Kerberos 
servers are involved, each device must understand 
what key is to be used for what resources. 

The inherent complexity of the Kerberos model 
is exacerbated by the modePs dependence on en- 
cryption. The Kerberos model would simply not 
work without its elaborate system of key based 
encryption. Each device must support shared se- 
cret key cryptography and understand how the 
keys are used within the Kerberos protocol. When 
a Kerberos client device receives an authorization 
request, it must know what key is to be associated 
with the client device, what key is to be associated 
with the server device, and what unique key can be 
used to communicate between the two devices. 
When the client device receives this information 
from the Kerberos server, it must understand that it 
needs to use its key to decrypt the message sent 
to it, that it cannot decrypt the message sent from 
the Kerberos server to the server device, and that it 
must use the new key to encrypt its response 
message to the server device. When the server 
device finally gets the message from the client 
device, it must understand that it needs to use its 
shared secret key to access the new key and that 
it must use the new key to access the information 
from the client device. This complexity is com- 
pounded when one remembers that each device 
can be involved in multiple connections. 

Yet another problem with the Kerbero's model 
and generally the nonintervention ist approach, is 
the lack of resource information available to client 
devices. Beyond the need to understand the loca- 
tion of system resources for registration purposes, 
each client must expressly inform the Kerberos 
server of the name of the particular server device 
with which it wishes to communicate. The Kerberos 
model does not contemplate authorization on an 
entity to information basis. In other words, a client 
device cannot simply say "I want access to in- 
formation X." A Kerberos server would reject such 
a request as lacking the appropriate server address 
information. 

It is a principal object of this invention to pro- 
vide an enhanced method and apparatus for com- 
municating data among the components of a com- 
puter system. 

It is another object of this invention to provide 
an enhanced method and apparatus for authorizing 
connections among the lOPs of a computer sys- 
tem. 

It is yet another object of this invention to 
provide an enhanced method and apparatus for 
authorizing connections among like entities. 



It is still another object of this invention to 
provide an enhanced method and apparatus for 
authorizing connections between a server entity 
and a plurality of client entities. 
5 It is still another object of this invention to 

provide an enhanced method and apparatus for 
authorizing connections between a plurality of serv- 
er entities and a single client entity. 

It is still another object of this invention to 
10 provide an enhanced method and apparatus for 
authorizing connections between a plurality of serv- 
er entities and a plurality of client entities. 

It is still another object of this invention to 
provide an enhanced method and apparatus for 
15 preventing rogue lOPs from accessing system re- 
sources. 

These and other objects are accomplished by 
the peer to peer connection authoriser disclosed 
herein. 

20 Conceptually, the authorization technique used 

by the disclosed peer to peer connection authorizer 
involves three different entities: a system authorizer 
mechanism, a client connection manager, and a 
server connection manager. The system authorizer 

25 resides on the main or primary CPU while the 
client and server connection managers reside on 
individual lOPs. 

To obtain information required by a user and/or 
an application program, the client connection man- 

30 ager issues a request to the system authorizer. 
Since the client application may or may not know 
the location of the desired information, the request 
may or may not include the address of a server 
device (i.e., the client connection manager will not 

35 provide the address of a server device when the 
location of the information is unknown to it). When 
the system authoriser receives the request, it first 
verifies that the client device is who it claims to be. 
The system authorizer then identifies the applicable 

40 server device by using either the address provided 
by the client connection manager or the information 
contained in the request. If the system authorizer 
determines that the client device should be allowed 
to access the information on the subject server 

45 device, it then sends a token to the server device 
and a copy of the same token to the client device. 
Depending on security needs, the token may or 
may not be encrypted. It is also possible that the 
requisite information resides on more than one 

so server device or that more than one client device 
requires the information. The system authoriser 
handles multiple device situations by dispatching 
multiple tokens and token copies. 

Upon receipt of the token copy from the sys- 

55 tern authorizer, the client connection manager 
packages the token copy into a message that it 
sends to the server device. When the server con- 
nection manager receives the message from the 
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client device, it compares the token copy to the 
token it received from the system authorizer. If the 
tokens match, the server connection manager re- 
sponds to the client device and the connection is 
established. If the tokens do not match, the server 
connection manager notifies the system authorizer 
of the failed connection attempt and then proceeds 
to inform the client device. 

Brief description of the drawings: 

Fig. 1 shows the computer system of the 
present invention. 

Fig. 2 shows the lOPs and the connection 
managers of the present invention. 

Fig. 3 shows a high level functional diagram of 
the message flow between the system authorizer 
and the client and server lOPs of the present 
invention. 

Fig. 4 shows block diagrams of the request 
message and the authorization and authorization 
response messages of the preferred embodiment. 

Fig. 5 shows block diagrams of the open and 
open response messages of the preferred embodi- 
ment. 

Fig. 6 shows block diagrams of the open, un- 
authorized open attempt, cancel token, and open 
response messages of the preferred embodiment. 

Fig. 7 shows a block diagram of the format of 
the token of the preferred embodiment. 

Fig. 8 shows a logic flow diagram of the sys- 
tem authorizer mechanism of the present invention. 

Fig. 9 shows a logic flow diagram of the server 
IOP connection manager of the present invention. 

Fig. 10 shows a logic flow diagram of the client 
IOP connection manager of the present invention. 

Fig. 1 shows a block diagram of the computer 
system of the present invention. The computer 
system of the preferred embodiment is an IBM 
AS/400 mid-range computer system. However, any 
computer system could be used. Fig. 1 shows an 
exploded view of computer system 100. Computer 
system 100 comprises main or central processing 
unit (CPU) 105 connected to primary memory 110 
and system I/O bus 115. Although the system 
depicted in Fig. 1 contains only a single main CPU 
and a single system I/O bus, it should be under- 
stood that the present invention applies equally to 
computer systems having multiple main CPUs and 
multiple I/O buses. Similarly, although the I/O bus 
of the preferred embodiment is a typical hardwired, 
multidrop bus, any connection means that supports 
bi-directional communication could be used. 

Connected to system I/O bus 115 are lOPs 
120. Although Fig. 1 shows six lOPs and four 
external devices, it should be understood that the 
present invention applies equally to any number 
external devices connected to any number of lOPs. 



Each of lOPs 120 is designed to communicate with 
bus 115 and the external device for which it is 
responsible. The processors used in the lOPs of 
the preferred embodiment (lOPs 120) are Motorola 

5 68020 micro computers, but other micro comput- 
ers, such as the Intel 960, could be used. System 
console 125 is connected to bus 115 via one of the 
lOPs 120. System console 125 allows system ad- 
ministrators to communicate with computer system 

10 100, normally through a non-programmable work- 
station. Similarly, magnetic storage 130, optical 
storage 135, and programmable workstation 140 
are each connected to bus 115 via one of lOPs 
120. Secondary storage devices 130 and 135 (i.e., 

is magnetic storage 130, and optical storage 135) are 
used by computer system 100 as large storage 
repositories for data and programs. Programmable 
workstation 140 allows users and developers to 
communicate with computer system 100. 

20 Primary memory 110 contains system 

authorizer mechanism 112 and operating system 
114. System authorizer 112 is shown to reside in 
primary memory 110. However, it should be under- 
stood that while system authorizer 112 will typically 

25 be loaded into primary memory to execute, it may 
at some point reside in magnetic storage 130 or 
optical storage 135. 

Fig. 2 shows an exploded view of two of lOPs 
120. As shown, lOPs 200 and 250 are used as 

30 interfaces between I/O bus 115 and devices 230 
and 260. Focusing on IOP 200, Fig. 2 shows that 
CPU 210, bus interface 205, primary memory 215 
and device interface 220 are all interconnected via 
bus 225. Residing in primary memory 215 is IOP 

35 connection manager 217. 

While in many cases bus interface 205, CPU 
210, primary memory 215, and bus 225 are the 
same in each of lOPs 120, IOP connection man- 
ager 217 and device interface 220 are usually 

40 device dependent. In other words, IOP connection 
manager 217 and device interface 220 may vary 
depending upon the nature of device 230. For 
example, if device 230 is a magnetic storage de- 
vice, IOP connection manager 217 will usually be a 

45 server connection manager and device interface 
220 will comprise input/output hardware commen- 
surate with the magnetic storage device. If, in con- 
trast, device 230 is a programmable workstation 
(PWS), IOP connection manager 217 will be a 

so client connection manager and device interface 220 
will similarly comprise input/output hardware com- 
mensurate with the PWS. 

Fig. 3 shows a functional flow diagram of the 
interaction between system authorizer 112 and 

55 server connection manager 300 and client connec- 
tion manager 350. Two different types of logical 
connections are shown on Fig. 3. Services connec- 
tions 320, 370, and 385 are used to pass connec- 
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tion oriented information while data connection 390 
is used for data transmission. Although in the fig- 
ures these connections appear as logical connec- 
tions, it should be understood that these connec- 
tions physically take place on I/O bus 115. In the 
preferred embodiment, the IBM Inter-process Com- 
munication Facility (IPCF) protocol is used to es- 
tablish these logical connections. However, any 
protocol capable of creating logical connections 
could be used. For more information about the 
IPCF protocol, refer to U.S. Patent 4,649,473 to 
Hammer et. al which is included herein by refer- 
ence. 

The names and locations of all of the lOPs are 
made known to system authorizer mechanism 112 
as part of the initialization sequence for computer 
system 100. Similarly, the bus address and name 
of system authorizer mechanism 112 are made 
known to each of the lOPs. The need for authoriza- 
tion first occurs when an application running on 
client device 380 requires access to resources that 
exist on a different device. Client connection man- 
ager 350 begins the authorization process by send- 
ing request message 360 to system authorizer 
mechanism 112 via services connection 370. Re- 
quest message 360 may indicate that a connection 
to a specific server IOP is desired or it may simply 
request access to particular information. 

System authorizer mechanism 112 reacts to 
request message 360 by sending Peer to Peer 
Authorization message (hereafter PTPA message) 
322 to server connection manager 300 via services 
connection 320. The format of PTPA message 322 
is shown on Figure 4. Although the fields and 
format of this message will be described in greater 
detail in the discussion associated with Figures 8- 
10, it is important to note the existence of server 
token 440. Server token 440 will be used later in 
the authorization process to determine whether 
server connection manager 300 should comply with 
an open request from a client connection manager. 
It is also important to note that server connection 
manager 300 only accepts tokens that are supplied 
by system authorizer mechanism 112. 

After receipt of PTPA message 322, server 
connection manager 300 uses services connection 
320 to respond to system authorizer mechanism 
112 with Authorization Response (AR) message 
324. If all is well with AR message 324, system 
authorizer mechanism 112 uses services connec- 
tion 370 to send Open Peer to Peer System to IOP 
message (hereafter OPTPSTI message) 374 to cli- 
ent connection manager 350. The format of OPT- 
PSTI message 374 is shown on Fig. 5. Although 
the fields and format of this message will be de- 
scribed in greater detail in the discussion asso- 
ciated with Figs. 8-10, it is important to note the 
existence of server copy token 525. Server copy 



token 525 is used by client connection manager 
350 to validate its resource request with server 
connection manager 300. Client connection man- 
ager 350 bundles server copy token 525 into Open 

5 Peer to Peer IOP to IOP message (hereafter OPT- 
PITI message) 375 and sends the message to 
server connection manager 300 via services con- 
nection 385. (The format of OPTPITI message 374 
is shown on Fig. 6.) 

10 Upon receipt of OPTPITI message 375, server 

connection manager 300 compares server copy 
token 615 to server token 440. If the tokens match, 
server connection manager 300 sends Open Peer 
to Peer IOP to IOP response message (hereafter 

75 OPTPITIR message) 325, via services connection 
385, to inform client connection manager 350 that 
access has been authorized. The data connection 
is then set up over data connection 390. 

If the tokens do not match, server connection 

20 manager 300 informs system authorizer 112 of the 
invalid access attempt by sending Unauthorized 
Open Attempt message (hereafter UOA message) 
310 via services connection 320. After dispatching 
this message, server connection manager 300 

25 sends OPTPITIR message 325, via services con- 
nection 385, to inform client connection manager 
350 that its access attempt has been rejected. 

When system authorization mechanism 112 re- 
ceives an UOA message, it has the responsibility of 

30 taking appropriate action. The appropriate action 
may range from "doing nothing" to sending a Can- 
cel Token message (hereafter CT message) to 
server connection manager 350. The CT message 
is a command which effectively tells server con- 

35 nection managers to refrain from accepting access 
attempts that are associated with the subject token. 

Upon receipt of OPTPITIR message 325, client 
connection manager 350 is required to inform sys- 
tem authorizer 112 of the outcome of the access 

40 attempt. To do so, client connection manager 350 
sends Open Peer to Peer System to IOP Response 
message (hereafter OPTPSTIR message) 360 to 
system authorizer 112 via services connection 370. 
Figs. 4-6 show the formats used for the mes- 

45 sages of the preferred embodiment. These formats 
are described in detail in connection with the fol- 
lowing discussion of Figs. 8-10. 

Fig. 8 shows a flow diagram of the steps taken 
by system authorizer mechanism 112 to authorize 

so peer to peer connections. For the purposes of 
explanation, assume that client device 380 of Fig. 3 
is a PWS running a multimedia application and that 
server device 340 of Fig. 3 is an optical storage 
device. Further assume that optical storage device 

55 340 contains multimedia information that is re- 
quired by the multimedia application running on 
PWS 380 and that client and server connection 
managers 350 and 300 of Fig. 3 are running on the 
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lOPs associated with PWS 380 and optical storage 
device 340 respectively. 

In block 800, system authorizer mechanism 
112 obtains and stores in an appropriate table the 
names and locations of all the lOPs of computer 5 
system 100. As stated, this is accomplished as part 
of the initialization of computer system 100. 

After initialization in block 800, system 
authorizer mechanism 112 waits for authorization 
requests 806. System authorizer mechanism 112 w 
will return to this wait state whenever processing of 
an authorization request has been completed. 
Blocks 805 and 810 represent two different types 
of authorization requests. External authorization re- 
quest 810 represents a request that originated in a 75 
device external to computer system 100. In the 
case at hand, the external request originated with 
multimedia PWS 380. Internal authorization request 
805 represents a request that is system initiated. 
This latter request will be described in connection 20 
with the discussion of the first alternate embodi- 
ment. 

When the multimedia application running on 
PWS 380 requires multimedia information, it will 
cause client connection manager 350 to send a 25 
request message to system authorizer mechanism 
112. 

Fig. 4 shows the format of the request mes- 
sage. This is the format that is used, for example, 
in request message 360. Request message format 30 
400 comprises client resource ID field 410, server 
resource ID field 415, information ID field 420, and 
access rights field 425. Client resource ID field 410 
is used to identify the client device that requires 
the information. In our multimedia example, the 35 
identity of PWS 380 would be contained in this 
field. Server resource ID field 415 is an optional 
field that contains location information about the 
server device. This field could be included in the 
message if the location of the requested inform a- aq 
tion is known to the client device. In our example, 
this field would be included if the multimedia ap- 
plication knew that the information it needed was 
stored on optical storage device 340. Information 
ID field 420 is used to identify the information or 45 
when the locate of that information is unknown to 
the requestor. For example, the multimedia applica- 
tion running on PWS 380 may know what informa- 
tion it needs, but not where the information is 
located. In this case, system authorization mecha- 50 
nism 112 uses information ID field 420 to deter- 
mine the whereabouts of the requested information. 
In the preferred embodiment, a table (not shown) 
which correlates particular information IDs to the 
location of the information is used; however, any 55 
means for associating a request for particular in- 
formation to the location of that information could 
be used. Access rights field 425 indicates what 



type of access the client device requires. For ex- 
ample, the multimedia application running on PWS 
380 may want to be authorized to write to as well 
as read from a particular storage device. 

System authorizer mechanism 112 will receive 
this request in functional block 810. Based on the 
nature of the request and general system factors, 
system authorizer mechanism 112 will determine 
the type of token, the number of tokens sent out, 
and the distribution of token types 815. General 
system factors may include current system re- 
source utilization, the location of the information, or 
any other factor that may affect how the request is 
processed. Blocks 820, 825, and 830 show the 
three different types of tokens that can be used. If 
system authorizer mechanism 112 chooses the sin- 
gle-use token type (shown as choice 830), the 
token or tokens that are sent out to the server or 
servers are used once and then destroyed. In our 
multimedia example, system authorizer mechanism 
112 elects to use this token type when, based on 
the request from client connection manager 350, it 
determines that all the information could be ob- 
tained with a single access. In other words, system 
authorizer mechanism 112 may determine that the 
quantity or nature of the requested information is 
such that it may be retrieved without multiple ac- 
cess requests. 

To expand on this example, further assume 
that some of the requested information was located 
on optical storage device 340, but that the remain- 
ing information was located on another optical stor- 
age device (not shown). In the multimedia example, 
this may occur if the video information were stored 
on optical storage device 340 and the audio in- 
formation were stored on another optical storage 
device (not shown). When this is the case, system 
authorizer mechanism 112 sends single use tokens 
to server connection manager 300 and the server 
connection manager associated with the second 
optical storage device (not shown). The manner in 
which these tokens are later used by the subject 
client connection manager(s) is described in forth- 
coming paragraphs. 

Reusable tokens (shown as choice 825) are 
used when system authorizer mechanism 112 de- 
termines that continued access to the information is 
required. In our example, system authorizer 
mechanism 112 may determine from the informa- 
tion supplied by client connection manager 350 
that the multimedia application running on PWS 
380 will require continued access to the information * 
stored on optical storage device 340. Once again, 
the example is expanded by assuming that contin- 
ued access to information stored on an additional 
optical storage device (not shown) is also required. 
If this were the case, system authorizer mechanism 
112 would send reusable tokens to server connec- 
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tion manager 300 and the server connection man- 
ager associated with the second optical storage 
device (not shown). 

The choice between a single-use token and a 
reusable token may also involve a tradeoff between 
security and performance. System authorizer 
mechanism 112 may choose to use a single ac- 
cess token over a reusable token when the in- 
formation requested is sensitive in nature. Similarly, 
system authorizer mechanism 112 may choose to 
use a reusable token over a single-use token when 
overall system performance is a primary concern. 

The last type of token, the generic token 
(shown as choice 820), is used to allow free access 
to the information on a particular server device. In 
our multimedia example, this may occur if system 
authorizer mechanism 112 determines that client 
devices other than PWS 380 will likely be in need 
of the information stored on optical storage device 
340 and that such access should be freely granted. 
Once again, system authorizer mechanism 112 
could determine that these conditions exist for 
more than just optical storage device 340 and send 
out multiple generic tokens. 

As above, system authorizer mechanism 112 
may also elect to use a generic token over the 
other types of tokens because of system perfor- 
mance concerns. 

The encryption option (shown as decision 
block 835) is included in the preferred embodiment 
to provide additional security if required. It is im- 
portant to note, however, that the present invention 
does not rely on the presence of encryption capa- 
bility to perform its authorization function. As 
shown on Fig. 8, the encryption option does not 
make sense when generic tokens have been cho- 
sen. 

Once the requested information has been lo- 
cated and the token or tokens of a particular type 
have been created (and possibly encrypted), sys- 
tem authorizer mechanism 112 bundles it/them into 
a PTPA message and sends the message(s) to the 
subject server connection manager(s). Figure 4 
shows the format of the PTPA message in more 
detail. Field 430 contains the PTPA message type 
indicator. 

Field 435 is used within the IPCF protocol to 
identify the entity for which the authorization is 
intended. Client access field 450 is used to indicate 
to the receiving server connection manager (here, 
server connection manager 300) what access rights 
have been requested by the client. Field 440 con- 
tains the actual token itself while field 445 contains 
the token type. Token qualifier field 445 contains 
an indication of the particular token's type (i.e., 
single use, multiple use, or generic). Fig. 7 shows 
the token format used in the preferred embodi- 
ment. Token format 700 comprises client IOP ad- 



dress 705, client IOP resource 710, time of day 
715, and random value 720. Client IOP address 
705 is a field which contains the location of the 
client IOP. In our multimedia example, this field 

5 would contain the address of the IOP that is run- 
ning client connection manager 350. Client IOP 
resource 710 is a field which contains the iden- 
tification of the resource that is requesting the 
information. In our example, this field would contain 

w the identification of PWS 380. Time of day field 
715 and random value 720 are used for uniqueness 
and encryption purposes should additional security 
be required. 

In our example, the token would be sent to 

75 server connection manager 300 and perhaps others 
845. Once this is accomplished, system authorizer 
mechanism 112 will determine whether the nature 
of the request and/or general system factors re- 
quire the use of another token type 850. This 

20 scenario can be best explained by reconsidering 
our expanded multimedia example. Beyond assum- 
ing that the required information is located on more 
than one server device, assume further that the 
access needs for the server devices are different. 

25 For example, the multimedia application may need 
continuous access to the video information stored 
on optical storage device 340, but only a single 
access to the audio information stored on the other 
optical storage device (not shown). If this were the 

30 case, system authorizer mechanism 112 would 
elect to send a reusable token to server connection 
manager 300 and a single-use token to the server 
connection manager (not shown) associated with 
the other optical storage device (not shown). 

35 When all of the PTPA messages have been 

dispatched, system authorizer mechanism 112 will 
begin processing the AR messages that it has 
received 855. The format of the AR message is 
shown on Fig. 4. AR format 470 comprises mes- 

40 sage type field 455 and status field 460. Status 
field 460 is used by system authorizer 112 to 
determine whether it is appropriate to proceed. For 
example, it would not be appropriate to continue if 
status field 460 indicated that optical storage de- 

45 vice 340 was currently unavailable. 

Assuming that all is well, system authorization 
mechanism 112 will proceed to build the necessary 
OPTPSTI message(s) at step 860. The format of 
the OPTPSTI message is shown on Fig. 5. OPT- 

50 PSTI message format 500 comprises message 
type field 505, client resource ID field 510, server 
resource ID field 515, server route field 520, server 
copy token 525, and client access field 530. Client 
resource ID field 510 identifies the client device for 

55 which the authorization is intended. In our case, 
PWS 380 has made the request and is, therefore, 
the client device which has been authorized to 
access the information stored on optical storage 
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device 340. Server route field 520 contains location 
information that is used by client connection man- 
ager 350 to initiate the connection between PWS 
380 and optical storage device 340. Server copy 
token field 525 contains the copy of the token that 
must be used to gain access to the information 
stored on optical storage device 340. Lastly, client 
access field 530 is used to inform client connection 
manager 350 of the access rights that have been 
authorized. 

When the appropriate message(s) has been 
created, it is sent to client connection manager 350 
in block 865. At this point, system authorizer 
mechanism 112 waits to get a response back from 
client connection manager 350 in block 870. Fig. 5 
shows the format of the OPTPSTIR message. OPT- 
PSTIR message format 550 comprises message 
type field 555, client status field 560, and server 
status field 565. The status field in each message 
is used to indicate the status of the subject device. 
The status fields are processed in block 880 of Fig. 
8. If the authorized connection took place, the 
status fields will so indicate. (The manner in which 
connections are made is described in the discus- 
sion of Figs. 9-10.) If a connection did not take 
place, the fields will cause system authorizer 
mechanism 112 to take remedial action (not 
shown). This remedial action could range from "do- 
ing nothing" to canceling the appropriate tokens. 

The manner in which system authorizer 
mechanism 112 processes the UOA message 
(shown in block 890) will be described in connec- 
tion with the discussion of Fig. 9. 

Fig. 9 shows the process flow for server con- 
nection manager 300. In the description of Fig. 8, 
block 845, we saw that the PTPA message(s) were 
sent from system authorizer 112 to server connec- 
tion manager 300. (Refer to the discussion of Fig. 8 
for a detailed description of the format of the PTPA 
message.) Server connection manager 300 re- 
ceives this message(s) in functional block 900 and 
proceeds to process the message(s) in block 970. 
In block 975, server connection manager 300 de- 
termines wheth- er it is possible to process the 
request associated with the message(s). It may not 
be possible if, for example, optical storage device 
340 was inoperable at the time of the request or if 
the IOP itself did not have enough resources to 
process the request If this were the case, connec- 
tion manager 300 would so indicate in its AR 
message to system authorizer mechanism 112 
(shown by blocks 975 and 942) and complete 932. 
(Refer to the discussion of Fig. 8 for a detailed 
description of the format of the AR message.) If it 
is appropriate for server connection manager 300 
to continue, the encryption option is dealt with 
(shown by blocks 980 and 952) and the token is 
stored 985. Server connection manager 300 will 



then send the appropriate AR message back to 
system authorizer mechanism 112 (shown by block 
990) and complete 962. 

Refer now to Fig. 10. (The remaining blocks of 

5 Fig. 9 relate to processing that is associated with 
messages that are sent by client connection man- 
ager 350 and system authorizer mechanism 112. 
These blocks are better understood when the origin 
of these messages has been explained.) Fig. 10 

w shows that the OPTPSTI message from system 
authorizer 112 is received by client connection 
manager 350 in block 1000. Client connection man- 
ager 350 responds to the OPTPSTI message from 
system authorizer 112 by creating and sending an 

75 OPTPITI message to server connection manager 
300. Fig. 6 shows the format of the OPTPITI mes- 
sage. OPTPITI message 600 comprises message 
type 605, server resource ID 610, and server copy 
token 615. Server resource ID field 610 is used to 

20 identify the resource which contains the required 
information. Server copy token field 615 contains 
the copy token that was received from system 
authorizer 112. 

Referring back to Fig. 9, the OPTPITI message 

25 is received by server connection manager 300 in 
block 920. After dealing with optional encryption 
(shown by blocks 945 and 960), server connection 
manager 300 determines whether the copy token 
that it received in the OPTPITI message is valid 

30 950. The validation is performed by comparing the 
copy token to the token that was received in the 
PTPA message. If the token is valid, server con- 
nection manager 300 next asks whether it is appro- 
priate to continue processing the request 963. As 

35 above, connection manager 300 is concerned with 
whether the IOP and the device have enough re- 
sources to process the request associated with the 
token. After the token's validity and the availability 
of resources have been ensured, server connection 

40 manager 300 determines whether the token is a 
single use token 965. If the token is a single use 
token, it is destroyed 992 by deleting it from IOP 
storage. After this decision has been made, server 
connection manager 300 responds to client con- 

45 nection manager 350 with a OPTPITIR message 
982. Fig. 6 shows the format of a OPTPITIR mes- 
sage. OPTPITIR message 650 comprises message 
type field 620, transfer limits field 625, status field 
630, and client access field 633. Transfer limits 

so field 625 will contain such information as the maxi- 
mum size of message packets and the maximum 
speed at which they can be transmitted. Status 
field 630 is used to inform client connection man- 
ager 350 of the outcome of the open attempt. As 

55 above, client access field 633 is used to inform 
client connection manager 350 of the access rights 
that have been authorized. 
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If server connection manager 300 determines 
that the copy token is invalid, it will send an UOA 
message to system authorizer 112 (shown by block 
955) before responding to client connection man- 
ager 350. Fig. 6 shows the format of the UOA 
message. UOA message 655 comprises message 
type field 635, client resource ID field 640, client 
route field 643, the token that was used in the 
attempt 645 (i.e., the token contained in server 
copy token field 615 of the subject OPTPITI mes- 
sage), and time of day field 660. The client re- 
source ID field identifies the client device and the 
client IOP that are responsible for the rejected 
open attempt. In our multimedia example this 
would be PWS 380 and the associated IOP (iden- 
tified by client route field 643). This message is 
then processed by system authorizer mechanism 
112 in block 890 of Fig. 8. As stated, system 
authorizer mechanism 112 must determine what 
remedial action is required. If system authorizer 
mechanism 112 decides to cancel the valid token, 
it will send a CT message (not shown) to server 
connection manager 300. Fig. 6 shows the format 
of the CT message. CT message format 675 com- 
prises message type field 665, the token to be 
cancelled 670, and the client route that is asso- 
ciated with the token to be cancelled 673. This 
message is received by server connection man- 
ager 300 in block 925 of Fig. 9. Server connection 
manager 300 responds to the CT message by 
destroying the token 930 for the specified IOP. 
Server connection manager 300 then completes 
processing 940. 

Referring lastly to Fig. 10, client connection 
manager 350 will receive the OPTPITIR message 
from server connection manager 300 in block 1015. 
If the status field of the OPTPITIR message in- 
dicates that a connection has been authorized, 
client connection manager 350 will initiate the au- 
thorized data connection 1015 and send a OPT- 
PSTIR message 1020 to system authorizer mecha- 
nism 112 to notify it of such. If the OPTPITIR 
message indicates that a connection has not been 
authorized, client connection manager 350 must 
nevertheless use an OPTPSTIR message to notify 
system authorizer mechanism of the failed attempt. 
Although this action is required of the client IOP, a 
rogue client IOP that does not comply with the 
requirement will not go undetected. As mentioned 
above, the server connection manager also has the 
responsibility of notifying the system authorizer 
(see block 955 of Fig. 9). 

In the first alternate embodiment, system 
authorizer mechanism 112 receives the authoriza- 
tion request internally from computer system 100 
itself 805. This would occur when an application 
running on CPU 105 determined that the devices 
associated with two or more lOPs should work 



together to achieve a particular task. At this point 
the authorization process would continue as has 
been described above. 

In the second alternate embodiment, the 

5 present invention is applied to a network of com- 
puters. It should be understood that while the pre- 
ferred embodiment uses the present invention to 
authorize connections between the lOPs of a single 
computer system, the present invention can also 

70 be used in a network environment. In this alternate 
embodiment, lOPs 120 are replaced by one or 
more independent computers and bus 115 is re- 
placed one or more physical networking interfaces. 
Examples of such interfaces include: IEEE 802.5 

75 (Token Ring), IEEE 802.4 (Token Bus), IEEE 802.3 
(Ethernet), FDDI, X.25, and ISDN. The methods 
and apparatus described in the primary and first 
alternate embodiment apply equally to this embodi- 
ment 

20 Although a specific embodiment along with 

certain alternate embodiments have been dis- 
closed, it will be understood by those skilled in the 
art that additional variations in form and detail may 
be made within the scope of the following claims. 

25 

Claims 

1. A method for communicating data, said meth- 
od comprising the steps of: 
30 - requesting access to system resources, 

said access being requested by a first 
connection manager, said first connec- 
tion manager residing on a first IOP; 

- sending an authorization token in re- 
35 sponse to said requesting step, said au- 
thorization token being sent from a sys- 
tem authorizer mechanism to a second 
IOP connection manager, said second 
IOP connection manager residing on a 

40 second IOP, said authorization token be- 

ing sent as part of a first message, said 
first message being transmitted on a bus; 

- sending a copy of said authorization to- 
ken from said system authorizer to said 

45 first IOP connection manager, said au- 

thorization token being sent as part of a 
second message, said second message 
being transmitted on said bus; 

- requesting a connection with said first 
so IOP connection manager, said connec- 
tion being requested via a third message, 
said third message comprising said copy 
of said token, said third message being 
transmitted via said bus; 

55 - validating said copy of said authorization 

token, said copy of said authorization to- 
ken being validated by said second IOP 
connection manager; 
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- establishing a connection between said 
first and said second lOPs across said 
bus based on the outcome of said vali- 
dating step. 

5 

The method of claim 1 wherein said sending 
an authorization token step comprises at least 
one of the following steps: 

- sending a generic authorization token; 

- sending a reusable authorization token; io 

- sending a single-use authorization token; 

- encrypting said authorization token; 

- sending said authorization token to a first 
server IOP connection manager and to a 
second server IOP connection manager. 75 

A method for communicating data between a 
client entity and a server entity, said method 
comprising the steps of: 

- issuing a request for data; 20 

- receiving in conjunction with said request 
an authorization token, said authorization 
token being received at said server en- 
tity, said authorization token being sent 
from a authorizer entity; 25 

- sending a copy of said authorization to- 
ken from said authorizer entity to said 
client entity; 

- requesting a connection, said connection 
being requested via a message sent 30 
from said client entity to said server en- 
tity, said message comprising a copy of 

said authorization token; 

- validating said copy of said authorization 
token, said copy of said authorization to- 35 
ken being validated by said server entity; 

- establishing a connection between said 
server entity and said client entity when 
said authorization token has been vali- 
dated. 40 

The method of any of the preceding claims 
wherein said sending a copy of said authoriza- 
tion token step comprises at least one of the 
following steps: 45 

- encrypting said copy of said authoriza- 
tion token; 

- sending said copy of said authorization 
token to a first client connection manager 

and to a second client connection man- 50 
ager; 

- sending said copy of said authorization 
token to a first client entity and a second 
client entity. 

55 

A method for communicating data, said meth- 
od comprising the steps of: 

- issuing a request for data; 



- receiving in conjunction with said request 
an authorization token, said authorization 
token being received at a client entity, 
said authorization token being sent from 
an authorizer entity; 

- requesting a connection between said cli- 
ent entity and a server entity, said con- 
nection being requested via a first mes- 
sage sent from said client entity to said 
server entity, said message comprising 
said authorization token; 

- establishing a connection between said 
client entity and said server entity based 
on a response received as a result of 
said requesting step. 

6. The method of any of the preceding claims 
wherein said establishing step comprises at 
least one of the following steps: 

- reporting the outcome of said validating 
step to said client IOP connection man- 
ager; 

- reporting the outcome of said validating 
step to said system authorizer; 

- reporting the outcome of said validating 
step to said client entity; 

- reporting the outcome of said validating 
step to said authorizer entity. 

7. A method for communicating data between a 
client entity and a server entity, said method 
comprising the steps of: 

- receiving in conjunction with a request 
for data a first authorization token, said 
authorization token being received at 
said server entity, said authorization to- 
ken being sent from an authorizer entity; 

- validating a second authorization token, 
said validation being done by comparing 
said second authorization token with said 
first authorization token, said second au- 
thorization token being received as part 
of a request to establish a connection 
between said server entity and said client 
entity. 

8. The method of any of the preceding claims 
wherein said receiving step comprises at least 
one of the following steps: 

- encrypting said authorization token; 

- receiving said authorization token at a 
first server entity and at a second server 
entity; 

- receiving a generic authorization token; 

- receiving a reusable authorization token; 

- receiving a single-use authorization to- 
ken. 
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9. The method of any of the preceding claims 
wherein said validating step comprises at least 
one of the following steps: 

- encrypting said authorization token; 

- decrypting said authorization token; 

- decrypting said authorization token and 
said copy of said authorization token. 

10. An apparatus for communicating data, said ap- 
paratus comprising: 

- means for requesting access to system 
resources, said access being requested 
by a first connection manager, said first 
connection manager residing on a first 
IOP; 

- means for sending an authorization token 
in response to said requesting step, said 
authorization token being sent from a 
system authorizer mechanism to a sec- 
ond IOP connection manager, said sec- 
ond IOP connection manager residing on 
a second IOP said authorization token 
being sent as part of a first message, 
said first message being transmitted on a 
bus; 

- means for sending a copy of said au- 
thorization token from said system 
authorizer to said first IOP connection 
manager, said authorization token being 
sent as part of a second message, said 
second message being transmitted on 
said bus; 

- means for requesting a connection with 
said first IOP connection manager, said 
connection being requested via a third 
message, said third message comprising 
said copy of said token, said third mes- 
sage being transmitted via said bus; 

- means for validating said copy of said 
authorization token, said copy of said au- 
thorization token being validated by said 
second IOP connection manager; 

- means for establishing a connection be- 
tween said first and said second lOPs 
across said bus based on the outcome of 
said validating step. 

11. The apparatus of claim 36 wherein said means 
for sending authorization token comprises at 
least one of the following means: 

- means for sending a generic authoriza- 
tion token; 

- means for sending a reusable authoriza- 
tion token; 

- means for sending a single-use authori- 
zation token. 



12. An apparatus for communicating data between 
a client entity and a server entity, said appara- 
tus comprising: 

- means for issuing a request for data; 

5 - means for receiving in conjunction with 

said request an authorization token, said 
authorization token being received at 
said server entity, said authorization to- 
ken being sent from a authorizer entity; 

io - means for sending a copy of said au- 

thorization token from said authorizer en- 
tity to said client entity; 

- means for requesting a connection, said 
connection being requested via a mes- 

75 sage sent from said client entity to said 

server entity, said message comprising a 
copy of said authorization token; means 
for validating said copy of said authoriza- 
tion token, said copy of said authorization 

20 token being validated by said server en- 

tity; 

- means for establishing a connection be- 
tween said server entity and said client 
entity when said authorization token has 

25 been validated. 

13. An apparatus for communicating data, said ap- 
paratus comprising: 

- means for issuing a request for data; 

30 - means for receiving in conjunction with 

said request an authorization token, said 
authorization token being received at a 
client entity, said authorization token be- 
ing sent from an authorizer entity; 

35 - means for requesting a connection be- 

tween said client entity and a server en- 
tity, said connection being requested via 
a first message sent from said client 
entity to said server entity, said message 

40 comprising said authorization token; 

- means for establishing a connection be- 
tween said client entity and said server 
entity based on a response received as a 
result of said requesting step. 

45 

14. The apparatus of any of the preceding claims 
wherein said means for establishing comprises 
at least one of the following means: 

- means for reporting the outcome of said 
50 means for validating to said client IOP 

connection manager; 

- means for reporting the outcome of said 
means for validating to said system 
authorizer; 

55 - means for reporting the outcome of said 

validating step to said authorizer entity; 
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15. An apparatus for communicating data between 
a client entity and a server entity, said appara- 
tus comprising: 

- means for receiving in conjunction with a 
request for data a first authorization to- 5 
ken, said authorization token being re- 
ceived at said server entity, said authori- 
zation token being sent from an 
authorizer entity; 

- means for validating a second authoriza- w 
tion token, said validation being done by 
comparing said second authorization to- 
ken with said first authorization token, 

said second authorization token being re- 
ceived as part of a request to establish a 75 
connection between said server entity 
and said client entity. 

16. The apparatus of any of the preceding claims 
wherein said means for receiving comprises at 20 
least one of the following means: 

- means for receiving a generic authoriza- 
tion token; 

- means for receiving a reusable authoriza- 
tion token; 25 

- means for receiving a single-use authori- 
zation token; 
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